home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / isis / isis-minutes-90july.txt < prev    next >
Text File  |  1993-02-17  |  6KB  |  142 lines

  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6.  
  7. Reported by Ross Callon/DEC
  8.  
  9. IS-IS Minutes
  10.  
  11. The IS-IS Working Group met the morning of August 1, 1990, at the IETF
  12. meeting in Vancouver, BC. We reviewed the most current Integrated IS-IS
  13. specification.
  14.  
  15. The greatest amount of discussion was on the authentication field.
  16. Several problems with the current text in the spec were pointed out.
  17. Also, whatever we do will probably conflict with whatever the
  18. authentication folks eventually tell us to do.  One option was therefore
  19. to go back to what was originally in the spec, which is to leave the
  20. contents of the authentication field unspecified.  However, there is an
  21. urgent need for the most basic form of error supression.  For example,
  22. it is very useful to provide a simple mechanism for preventing
  23. mis-configuration of a single link from causing two large routing
  24. domains to inadvertantly merge into one domain.
  25.  
  26. After a great deal of discussion, it was agreed that we would like to do
  27. just about the same thing that OSPF already does:  provide a simple
  28. password mechanism with an escape to allow future identification of
  29. other mechanisms.  Ross Callon (as editor for the IS-IS specification)
  30. was instructed to remove the details of the authentication field from
  31. the main body of the spec, specifying the contents of the field as ``to
  32. be determined'', and to provide an annex to the spec specifying how to
  33. use the authentication field for carrying a simple password.  Also, we
  34. agreed to use the same value for the authentication type field as used
  35. by OSPF, in the off-chance that future assignments between
  36. authentication type fields could be kept in alignment.
  37.  
  38. It was pointed out that the current definition of the manner of carrying
  39. TAG information in the ``interdomain routing protocol information
  40. field'' was difficult to process (in particular, it required that before
  41. processing an ``IP External Reachability Information'' field, the
  42. implementation would first have to check what the following field is,
  43. and if it is an ``Interdomain Routing Protocol Information'' field, then
  44. process the two fields in parallel).  After discussion, an alternate
  45. encoding was agreed upon.
  46.  
  47. There was a discussion of the possibility that the amount of information
  48. carried in the Inter-Domain Routing Protocol Information field may be
  49. large, and that in some cases the bulk of level 2 routers (those that
  50. don't do inter-domain routing directly) would therefore be required to
  51. store information that they don't have any use for.  This would appear
  52. to mean that folks determining how to use this field need to give
  53. careful consideration to what inter-domain routing information should be
  54. put into this field, and what should be carried by other means.  Ross
  55. agreed to add a note to the spec describing this issue.
  56.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64. The limit on the maximum number of addresses that can be assigned to a
  65. single interface was discussed.  There was general agreement that
  66. multiple IP addresses per interface was useful in some cases
  67. (particularly for transition), but there was no obvious reason to limit
  68. a router to two addresses per interface (as in the current spec).  It
  69. was agreed that a better limit was whatever number of addresses could
  70. fit into one occurrence of the ``IP Interface Address'' field in IS-IS
  71. Hello packets, which implies a maximum of 63 IP addresses per interface.
  72. It was agreed that this limit was plenty big enough, also that there was
  73. no need to pick a smaller limit.
  74.  
  75. Rob Hagens pointed out that the use of the term ``segmentation'' in
  76. section 3.6 was inconsistent with the terminology used in the OSI spec
  77. (the meaning was consistent, just the terminology was different).  Ross
  78. agreed to fix this.
  79.  
  80. It was agreed that after these changes were made, the spec was ready to
  81. be published as an Internet Draft, and submitted as an RFC. Ross agreed
  82. to send the draft spec to the Working Group first in case anyone could
  83. find any nits.
  84.  
  85. A few other minor editorial nits were also transmitted to Ross during
  86. side discussions.
  87.  
  88. Attendees
  89.  
  90.  
  91. Karl Auerbach            auerbach@csl.sri.com
  92. Fred Baker               baker@vitalink.com
  93. Art Berggreen            art@opal.acc.com
  94. Chet Birger              cbirger@bbn.com
  95. Ross Callon              callon@bigfut.enet.dec.com
  96. C. Allan Cargille        cargille@cs.wisc.edu
  97. Curtis Cox               zk0001@nhis.navy.mil
  98. Farokh Deboo             fjd@interlink.com
  99. Dino Farinacci           dino@buckeye.esd.3com.com
  100. Jeffrey Fitzgerald       jjf@fibercom.com
  101. Chris Gunner             gunner@osicwg.enet.dec.com
  102. Yong Guo                 guo@cs.ubc.ca
  103. Robert Hagens            hagens@cs.wisc.edu
  104. Tony Hain                alh@eagle.es.net
  105. Susan Hares              skh@merit.edu
  106. Peter Harrison           harrison@miden.ucs.unimelb.edu.au
  107. Kathleen Huber           khuber@bbn.com
  108. Paulina Knibbe           knibbe@cisco.com
  109. Holly Knight             holly@apple.com
  110. Alex Koifman             akoifman@bbn.com
  111. Gregory Lauer            glauer@bbn.com
  112. Walter Lazear            lazear@gateway.mitre.org
  113. Solomon Liou             solomon%penril@uunet.uu.net
  114. Yoni Malachi             malachi@polya.stanford.edu
  115. Douglas Montgomery       dougm@osi3.ncsl.nist.gov
  116. Rebecca Nitzan           nitzan@nsipo.nasa.gov
  117.  
  118.                                    2
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125. Zbigniew Opalka          zopalka@bbn.com
  126. Brad Parker              brad@cayman.com
  127. Michael Reilly           reilly@nsl.dec.com
  128. Jim Reinstedler          jimr@ub.com
  129. Jim Showalter            gamma@mintaka.dca.mil
  130. Keith Sklower            sklower@okeeffe.berkeley.edu
  131. Frank Solensky           solensky@interlan.interlan.com
  132. John Veizades            veizades@apple.com
  133. Chris Weider             clw@merit.edu
  134. Steve Willis             swillis@wellfleet.com
  135. Walter Wimer             ww0n+@andrew.cmu.edu
  136. Linda Winkler            b32357@anlvm.ctd.anl.gov
  137. Allan Young              rcoay@possum.ecg.rmit.oz.au
  138.  
  139.  
  140.  
  141.                                    3
  142.